Method for determining a timeout delay in a network

ABSTRACT

A method for determining a remote timeout parameter in a network comprising a link between a first bus and a third bus. The link is implemented through a first and a second bridge portal connected respectively to the first and the third bus, and is modelized as a second bus connected to the first bus and the third bus through bridges. Upon solicitation to provide its contribution to a timeout for a request subaction, the first bridge portal adds to the timeout contribution the first bridge portal&#39;s maximum request subaction processing time and either the link&#39;s maximum transmission time of half of the link&#39;s maximum transmission time, depending on the location of the destination node of the request subaction.

This application claims the benefit, under 35 U.S.C. § 365 ofInternational Application PCT/EP01/12331, filed Oct. 18, 2001, which waspublished in accordance with PCT Article 21(2) on Apr. 25, 2002 inEnglish and which claims the benefit of European patent application No.00402900.5, filed Oct. 19, 2000.

FIELD OF THE INVENTION

The invention concerns a method for determining a timeout delay in acommunication network, in particular a network comprising a linkconnecting two IEEE 1394 busses. The link may for example be a wirelessHiperlan 2 link.

BACKGROUND ART

The response timeout problem has been treated as follows in a number ofstandards or draft standards:

(a) Situation in a Wired IEEE1394-1995 Bus Environment:

A split transaction is characterized by a request subaction and asubsequent responder subaction using the same transaction label (i.e. anidentifier of the transaction).

A value in the SPLIT_TIMEOUT control and status register specifies amaximum time period for a particular IEEE1394 node, in which theresponse to a request has to be generated and sent. If the specifiedtime period (or twice the time period as specified in the IEEE1394astandard respectively) has elapsed without a response being transmitted,the complete transaction fails and the transaction label can be reused(“recycled”) by the requesting node.

Reference: IEEE Standard for a High Performance Serial Bus (IEEE1394-1995), IEEE New York, 1996

IEEE Standard for a High Performance Serial Bus—Amendment 1(IEEE1394A-2000), IEEE New York, 2000

(b) Situation in the BRAN Hiperlan 21394 SSCS

The BRAN Hiperlan 2 IEEE1394 Service Specific Convergence technicalspecification describes how a Hiperlan 2 (HL2) link can be modeled as avirtual IEEE 1394 bus. Therefore, a HL2 split timeout is defined in afashion similar to an IEEE Std 1394-1995 split timeout, but with a 200ms default value instead of 100 ms.

An algorithm at the sending portal defines, with help of thisSPLIT_TIMEOUT value, a time_of_life period for each particularasynchronous request or response intended to be transmitted over the HL2wireless link. The time_of_life parameter will be converted to atime_of_death label attached to each asynchronous packet. Thistime_of_death label advises the receiver of this packet on the wirelesslink to discard it, if its intended end of life has been reached. Theformat of the SPLIT_TIMEOUT register defined by the SSCS documentdiffers slightly from the specifications IEEE 1394-1995 and IEEE1394a-2000.

Reference: IEEE 1394 Service Specific Convergence Sublayer(DTS/BRAN-00240004-3 V1.1.1), ETSI Project Broadband Radio AccessNetworks (BRAN), Sophia Antipolis, September 2000

(c) Proposed Situation in the IEEE P1394.1 Bridge Environment

Due to longer transmission delays in a bridge environment, this easysplit_timeout mechanism cannot be used anymore if split transactions areintended to pass bridges between busses. Instead of the ‘split_timeout’parameter, a ‘remote_timeout’ parameter is defined.

The ‘remote_timeout’ parameter in an IEEE P1394.1 bridge environment canbe determined by sending a message called a TIMEOUT bridge managementmessage with a particular ‘timeout’ opcode to a virtual node identifier.The virtual node identifier represents the destination node which, sinceit is not on the same bus as the requesting node, does not have aphysical identifier on the bus of the requesting node. In the responseto this packet, the requesting node will receive the accumulated maximumdelay times of all intermediate bridges.

The draft IEEE P1394.1 distinguishes different delay times in a bridgefor requests (MAX_RQ_FORWARD_TIME) and responses(MAX_RESP_FORWARD_TIME). These times are implementation dependent andhave to be provided by the manufacturer of the bridge.

A description of the ‘TIMEOUT bridge management message’ is given insection 6.7 of P1394.1 Draft D 0.11. Section 4.2 also describes theoverall process.

Reference: IEEE Draft Standard for High Performance Serial Bus Bridges(IEEE P1394.1 Vers. 0.11) IEEE 1391.1 working group (standard not yetapproved)

BRIEF SUMMARY OF THE INVENTION

Accordingly, the problem to solve is the following:

When a link such as a HL2 network is represented as an IEEE 1394 bus, aHL2 wireless bridge is used to wirelessly interconnect IEEE 1394 bridgeaware nodes. When two bridge aware nodes exchange asynchronous packetsover HL2, they cross two bridges. Therefore they have to use a remotetimeout that takes into account the two wireless bridges as well as theHL2 transmission time.

Note that the term ‘link’ designates any appropriate configuration of awireless (or wired) network, not simply a point-to-point link.

The invention concerns a method for determining a remote timeoutparameter in a network comprising a link between a first bus and a thirdbus, wherein the link is implemented through a first and a second portalconnected respectively to the first and the third bus, and wherein thelink is modelized as a second bus connected to the first bus and thethird bus through respective bridges;

-   -   the method comprising the steps, at the level of the first        bridge portal of, upon solicitation to provide its contribution        to a timeout for a request subaction:        -   (a) determining whether a destination node of the request            subaction is located on the link or not;        -   (b) in the affirmative, adding to the timeout contribution:            the first bridge portal's maximum request subaction            processing time and link's maximum transmission time;        -   (c) in the negative, adding, to the timeout contribution:            the first bridge portal's maximum request subaction            processing time and half of the link's maximum transmission            time.

When asked to specify its contribution to a timeout interval regarding afuture request subaction, a portal checks whether the destination nodeof the request subaction lies on the wireless link or not. Depending onthe answer to this question, the portal decides whether to contribute,in addition to its own processing or forwarding time, half or all of thelink maximum transmission time. Indeed, only half of the maximumtransmission time is added if it is expected that the request subactionwill be forwarded (or came from) the peer portal which will contribute(or has already contributed) the other half of this maximum transmissiontime. The process above concerns determination of timeout contributionfor request subactions. A symmetric approach applies to responsesubactions.

Other characteristics and advantages of the invention will appearthrough the description of a preferred embodiment of the invention,explained with the help of the unique drawing representing a diagram ofthe network of the present embodiment, including the different timeoutcontributions The process for a timeout response message is symmetric.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 illustrates two buses linked by a Hiperlan network via bridgeportals.

DEAILED DESCRIPTION OF THE INVENTION

The Timeout handling of Hiperlan 2 Bus Bridges according to theinvention is carried out as follows:

As illustrated by FIG. 1, Hiperlan bus bridges usually have one portalconnected to a wired IEEE1394 bus, the other portal being connected to awireless Hiperlan 2 network. To achieve compatibility to P1394.1bridges, Hiperlan 2 bridges must be able to process the Timeout BridgeManagement Message mentioned in the introduction.

Note that the invention could also be applied in other contexts thanthat of FIG. 1. In particular, the link is not necessarily a wirelesslink.

For this reason it is necessary that each Hiperlan 2 compliant busbridge provide values for the MAX_RQ_FORWARD_TIME andMAX_RESP_FORWARD_TIME parameters of the timeout message.

The MAX_RQ_FORWARD_TIME parameter represents the sum of time limits thateach bridge on the route from a requesting node to a destination node isallotted within which to forward a request subaction to the next bridge.Similarly, the MAX_RESP_FORWARD_TIME parameter represents the sum oftime limits for a response subaction. These two times may be different.

The following method describes how these MAX_RQ_FORWARD_TIME andMAX_RESP_FORWARD_TIME values are calculated.

Two cases are considered:

-   -   (1) a wired bridge aware device sends packets to a HL2 wireless        device connected to the HL2 ‘bus’, or    -   (2) a wired bridge aware device sends packets to another wired        bridge aware device over the HL2 bus.

(1) Sending Packets to a Wireless Device

When a bridge aware device (e.g. node 1) sends a request subactionpacket to a HL2 device (e.g. node 3), it will experience followingdelays:

-   -   Wireless bridge 1 internal request forwarding time (basically        the processing time of the internal switching fabric)    -   transmission time within the Hiperlan 2 network

Similarly when a bridge aware device (e.g. node 1) sends a responsesubaction packet to a HL2 device (e.g. node 3), it will experiencefollowing delays:

-   -   Wireless bridge 1 internal response forwarding time (basically        the processing time of the internal switching fabric)    -   transmission time within the Hiperlan 2 network (identical to        the HL2 request subaction transmission time)

(2) Sending Packets to a Wired Device over HL2

When a wired bridge aware device (e.g. node 1) sends a request subactionpacket to another wired bridge aware device (e.g. node 2) over HL2, itwill experience following delays:

-   -   Wireless bridge 1 internal request forwarding time (basically        the processing time of the internal switching fabric)    -   transmission time within the Hiperlan 2 network    -   Wireless bridge 2 internal request forwarding time

Similarly when a wired bridge aware device (e.g. node 1) sends aresponse subaction packet to another wired bridge aware device (e.g.node 2) over HL2, it will experience following delays:

-   -   Wireless bridge 1 internal response forwarding time (basically        the processing time of the internal switching fabric)    -   transmission time within the Hiperlan 2 network (identical to        the HL2 request subaction transmission time)    -   Wireless bridge 2 internal response forwarding time

The following mechanism is proposed:

1/ When a wireless bridge gets a TIMEOUT request message (bridgemanagement message with opcode=TIMEOUT, q=REQUEST), it checks thedestination_id field of the TIMEOUT bridge management message.

If the destination_id.bus_id field is the HL2 bus bus_id, then thewireless bridge shall increase the max rq_hold_seconds andmax_rq_hold_cycles fields with its own MAX_RQ_FORWARD_TIME plus the HL2maximum transmission time (½ HL2 T_(st)=100 ms). T_(st) is theSPLIT_TIMEOUT register value. On HL2 it is set to 200 ms (1394 SSCS TS).

The bridge portal also sets the ‘remote_split_timeout_seconds’ and‘remote_split_timeout_cycles’ fields of the TIMEOUT request message tothe corresponding HL2 SPLIT_TIMEOUT values, since the HL2 bus is thedestination bus. These values correspond to the time interval duringwhich the bridge will wait for the response from the wirelessdestination device.

If the destination_id.bus_id field is not the HL2 bus bus_id (i.e. thedestination_id is on the other side of the wireless network), then thewireless bridge shall increase the max_rq_hold_seconds andmax_rq_hold_cycles fields with its own MAX_RQ_FORWARD_TIME plus half ofthe HL2 maximum transmission time (½(½ HL2 T_(st))=50 ms). Then theTIMEOUT request message is sent to the next wireless bridge (which willperform a similar processing, so that at the end of the wirelesstransmission the TIMEOUT request message accumulated both bridgeMAX_RQ_FORWARD_TIME plus the HL2 maximum transmission time).

Similarly:

2/ When a wireless bridge gets a TIMEOUT response message (bridgemanagement message with opcode=TIMEOUT, q=RESPONSE), it shall check thedestination_id field of the TIMEOUT bridge management message (see 6.4of D0.11).

If the destination_id.bus_id field is the HL2 bus bus_id, then thewireless bridge shall increase the max_resp_hold_seconds andmax_resp_hold_cycles fields with its own MAX_RESP_FORWARD_TIME plus theHL2 maximum transmission time (½ HL2 T_(st)=100 ms)

If the destination_id.bus_id field is not the HL2 bus bus_id (i.e. thedestination_id is on the other side of the wireless network), then thewireless bridge shall increase the max resp_hold_seconds and maxresp_hold_cycles fields with its own MAX_RESP_FORWARD_TIME plus half ofthe HL2 maximum transmission time (½ (½ HL2 T_(st))=50 ms). Then theTIMEOUT response message is sent to the next wireless bridge (which willperform a similar processing, so that at the end of the wirelesstransmission the TIMEOUT response message accumulated both bridgeMAX_RESP_FORWARD_TIME plus the HL2 maximum transmission time).

In summary, for asynchronous traffic between a wired 1394 bus A over afirst Hiperlan 2 bus bridge I, a wireless Hiperlan 2 network B, a secondHiperlan 2 bus bridge II and a wired 1394 bus C, the HL bridge I willadd the first half, the HL bridge II will add the second half to themaximum transmission delay of the wireless bus B. For asynchronoustraffic between a wired 1394 bus A device and a HL2 bus device over awireless bridge I, the HL bridge I will add the whole maximumtransmission delay of the wireless bus B to its own internal maximumforward time.

By the adding the maximum transmission delay to maximum forward times,it is possible to hide the special properties of a wireless network tobridge aware node. In this case it will see no differences if itsrequest is routed via a wired, IEEE1394.1 compliant bridge or via aHiperlan 2 bridge.

The embodiment enables bridge aware nodes to work seamlessly over HL2bridges using only P1394.1 bridge-command mechanisms.

1. Method for facilitating data transmission over a network bydetermining a remote timeout parameter in a network comprising a linkcomprising the steps, at a level of a first bridge portal, uponsolicitation to provide its timeout contribution for a requestsubaction, of: (a) determining whether a destination node of the requestsubaction is located on the link or not, wherein the link represents asecond bus that is between a first bus and a third bus, wherein the linkis implemented through a first and a second bridge portal connectedrespectively to the first and the third bus, and wherein the link ismodelized as the second bus connected to the first bus and the third busthrough respective bridges; (b) if a destination node of the requestsubaction is located on the link representing the second bus, adding tothe timeout contribution: the first bridge portal's maximum requestsubaction processing time and the link's maximum transmission time,wherein the timeout represents the sum of time limits that each bridgeon a route from a requesting node to a destination node is allotted toforward the request subaction, the requesting node being on the firstbus, the destination node being on the link representing the second busor on the third bus; (c) if a destination node of the request subactionis not located on the link representing the second bus, adding to thetimeout contribution: the first bridge portal's maximum requestsubaction processing time and half of the link's maximum transmissiontime; and (d) deeming a data transmission attempt a failure if therequest subaction does not occur within a time interval defined by thetimeout contribution.
 2. Method according to claim 1, wherein, furtherto step (c), the second bridge portal adds, as its contribution, its ownmaximum request subaction processing time and half of the link's maximumtransmission time.
 3. Method according to claim 1, wherein the linkrepresenting the second bus is a Hiperlan 2 wireless network.
 4. Methodaccording to claim 3, wherein the maximum transmission time of thewireless link representing the second bus is equal to half of theHiperlan 2 IEEE 1394 SSCS ‘SPLIT_TIMEOUT’ register value of a portal. 5.Method according to claim 1, wherein the timeout contribution from thebridges is solicited through a timeout request message.
 6. Methodaccording to claim 5, wherein, further to step (b), the first bridgeportal sets remote_split_timeout fields of the timeout request messageto values in accordance with the Hiperlan 2 IEEE 1394 SSCS‘SPLIT_TIMEOUT’ register value of the first portal.
 7. Method forfacilitating data transmission over a network by determining a remotetimeout parameter in a network comprising a link comprising the steps,at the level of a first bridge portal, upon solicitation to provide itstimeout contribution for a response subaction associated with a requestsubaction, of: (a) determining whether a destination node of theresponse subaction is located on the link or not wherein the linkrepresents a second bus between a first bus and a third bus, wherein thelink is implemented throuah a first and a second bridge portal connectedrespectively to the first and the third bus, and wherein the link ismodelized as a second bus connected to the first bus and the third busthrough respective bridges; (b) if a destination node of the responsesubaction is located on the link representine the second bus, adding tothe timeout contribution: the first bridge portal's maximum responsesubaction processing time and the link's maximum transmission time toestablish the time delay for receiving a response from the destinationnode on the link representing the second bus, wherein the timeoutrepresents the sum of time limits that each bridee on a route from adestination node to a requesting node is allotted to forward theresponse subaction, the requesting node being on the first bus, thedestination node being on the link representing the second bus or on thethird bus; (c) if a destination node of the response subaction is notlocated on the link representing the second bus, adding to the timeoutcontribution: the first bridge portal's maximum response subactionprocessing time and half of the link's maximum transmission time, andforwarding a timeout contribution message to the second bridge portal;and (d) deeming a data transmission atlempt a failure if the requestsubaction does not occur within a time interval defined by the timeoutcontribution.
 8. Method according to claim 7, wherein, further to step(c), the second bridge portal adds as its contribution its own maximumresponse subaction processing time and half of the link's maximumtransmission time.
 9. Method according to claim 7, wherein the linkrepresenting the second bus is a wireless Hiperlan 2 network.
 10. Methodaccording to claim 9, wherein the maximum transmission time of thewireless link representing the second bus is equal to half of theHiperlan 2 IEEE 1394 SSCS ‘SPLIT₁₃ TIMEOUT’ register value of a portal.